Traditional bus protocols rely on a communication handshake to transmit a transaction between master and slave. A typical handshake takes the following form. The master places a transaction on the bus and the master asserts a command request signal. The transaction remains on the bus, preventing other transactions from being transmitted, until the slave asserts a command acknowledge signal indicating the transaction has been received. After processing is complete, the slave may optionally place a response on a separate bus and assert a response request. The response remains on the bus, preventing other responses from being transmitted, until the master asserts a response acknowledge signal indicating the response has been received.
This traditional bus communication handshake suffers from a performance loss due to the following factors. Transactions such as commands or responses may on the bus for multiple cycles when a request signal is asserted waiting for an acknowledge signal. This wait prevents other transactions from utilizing the bus. This reduces the number of transactions transmitted during the time period and reduces communication performance. This handshake requires a two way communication in order to transmit a transaction: a request signal from the transaction sender; and acknowledge signal from the transaction recipient. These two signals typically are in different cycles adding to the latency of single transaction processing.
Typical communication protocols transmit read, write, and coherence transactions on separate physical channels. Commands and responses are also typically transmitted on separate channels. As address and data widths increase, this results in a very large number of physical wires that must be routed during physical design. The resulting wire congestion can result in increased area, power consumption and lengthened design schedule. This wiring congestion can also result in decreased performance if the area increase leads to the insertion of additional pipeline stages.